Experience Report : Contributions of SFMEA to RequirementsAnalysisRobyn

This experience report describes the lessons learned from the use of Software Failure Modes and EEects Analysis (SFMEA) for requirements analysis of critical spacecraft software. The SFMEA process was found to be successful in identifying some ambiguous , inconsistent, and missing requirements. More importantly, the SFMEA process, followed by a backward analysis somewhat similar to Fault Tree Analysis (FTA), identiied four signiicant, unresolved requirements issues. These issues involved complex system interfaces and unanticipated dependencies. Our results challenge some current views on the limitations of SFMEA and suggest that recent eeorts by researchers to integrate SFMEA with a broader FTA approach have merit. 1. The Problem There are software programs onboard spacecraft that must autonomously detect, identify, and oversee the recovery of the spacecraft from faults during ight. Since these faults can threaten the well-being of the spacecraft and the success of its scientiic mission, the software that responds to such faults is considered to be critical by the development team. A fault is given the standard deenition here of being either \a defect in a hardware device or component" or \an incorrect step, process, or data deenition in a computer program" 4]. Those faults which can cause power loss, excessive temperature, propellant tank overpres-sure, interruption of uplink commandability, or loss of downlinked scientiic and engineering telemetry are detected and handled by onboard software. Requirements analysis of this critical software is diicult since the software is often both complex and highly coupled. The software that responds to faults is often dependent on other distributed software and hardware components (for example, a single hardware fault may aaect multiple software processes) and subject to timing constraints (for example, the software must provide quick recovery of functionality). These properties make the correct and complete spec-iication of requirements hard to determine and hard to validate. In particular, inadequate software responses to extreme conditions and boundary cases are of concern. Appropriate software responses to anomalous hardware behavior, unanticipated states, invalid data, and signal saturation are robustness issues that should be resolved, if possible, during the requirements phase. 2. Our Approach This experience report describes our use of Software Failure Modes and EEects Analysis (SFMEA), followed by a backward analysis somewhat similar to Fault Tree Analysis (FTA), to assist in analyzing the software requirements for critical portions of the spacecraft software. The approach was used on twenty-four software modules on two spacecraft systems , Cassini and Galileo. …